home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group99a.txt / 000171_icon-group-sender _Fri Jul 30 12:37:01 1999.msg < prev    next >
Internet Message Format  |  2000-09-20  |  2KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id MAA13972
  4.     for icon-group-addresses; Fri, 30 Jul 1999 12:35:39 -0700 (MST)
  5. Message-Id: <199907301935.MAA13972@baskerville.CS.Arizona.EDU>
  6. From: "Frank Lhota" <lhotaf@lexma.meitech.com>
  7. To: <icon-group@optima.CS.Arizona.EDU>
  8. Subject: When Do You Keep A Quirk?
  9. Date: Fri, 30 Jul 1999 11:39:17 -0400
  10. X-Priority: 3
  11. X-MSMail-Priority: Normal
  12. X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
  13. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  14. Status: RO
  15.  
  16. Gordon Peterson makes an excellent argument for moving to a less quirky
  17. definition of basename, going so far as to purposely break older programs
  18. that might depend on the quirks. I am totally sympathetic to this point of
  19. view. I had a friend that worked on the ANSI C standards committee. He
  20. frequently lamented that there were proposed changes to C that every
  21. committee member agreed would make a for a better language, but were voted
  22. down because they would break large, existing applications. One has to weigh
  23. the cost of revising old programs with the possible gains in new programs.
  24.  
  25. In the case of basename, there are over a dozen IPL sources that use
  26. basename. If these IPL programs have not been tested with the new version of
  27. basename, I would be very concerned about this change, for this can effect
  28. programs that are not even using basename directly. Of course, it is very
  29. hard to determine how much non-IPL code out there uses basename, or how many
  30. programs depend on the quirks. As much as I prefer the new version of
  31. basename, making this change in the short run is too risky.
  32.  
  33. If and when we do wish to change the behavior of basename, there is a way to
  34. ease the migration path. We can write a procedure old_basename that has the
  35. old behavior, then add the following line to old source files:
  36.  
  37.     $define basename old_basename
  38.  
  39. One final point: could we please cut down on ending Icon group mailings with
  40. political or religious messages? I say this not because I disagree (or
  41. agree) with the religious / political / aesthetic views of the members of
  42. the group. It's just that the purpose of the group is to exchange
  43. information on the Icon programming language. This is not the place for
  44. discussion of these other topics.
  45.  
  46.